看家本领之二：软件测试的分析性思维
教育的价值不是学习大量的客观知识，而是思维能力的训练
——阿尔伯特·爱因斯坦
上篇文章（ 看家本领之一：软件测试的系统性思维 ）和大家交流了软件测试的系统性思维，这是一种全局思维、整体思维，关注被测系统的各个要素及其之间的连接关系。系统性思维，主要帮助我们建立观察事物、分析问题的思维方式，往往可以理解为一个立场、一个态度或一个出发点，虽然其中也包括抽象和分解等过程，但总感觉缺少解决问题的完整思路，这时候，我们就想到分析性思维，它能够帮助我们建立一条解决问题的正确思路。
分析性思维（Analytical Thinking）属于逻辑思维、理性思维、科学性的思维方式，也可以说是“纵向思维”——根据逻辑不断深入问题的一种思维方式。分析性思维帮助我们建立一种循序渐进的思维方法，从收集问题的相关信息、比较不同来源的信息、明确真正的问题到得出适当的问题解决方案，一步一步地去解决问题：
明确要解决的问题，以及要达到的目的或目标；
为解决问题收集相关的各种数据、信息；
整理和分析数据、信息，为解决问题找到依据、原因；
分析和识别问题所面对的假设、条件、场景；
从依据、假定等处罚，进行逻辑推理，得出解决方案；
从工程角度看，得出一个解决方案还远没有结束，必须得到多个解决方案；
为评估解决方案设立评估标准，即评价什么样的解决方案是更优的方案；
基于评估标准，分析各个方案的利益、所带来的负面影响等；
基于上述评估分析（定性或定量），从上述方案中选出一个较优的方案；
给出明确的结论或观点，为结论做出合理的解释。
分析过程中还会采用一些定量分析或定性工具，如亲和图、因果图，最终会收敛到问题的答案或解决方案上。分析性思维是帮助我们解决复杂的问题，或者说，一旦经过了良好的分析性思维训练之后，咱们就能够快速有效地解决问题。
根据康奈尔大学教授Robert J. Sternberg 对人类认知的研究，人们的认知能力主要来源于分析性思维、创造性思维（后面文章会讨论）和实用性思维。从认知的层次看，分析能力的层次也比较高，是在记忆、理解、应用之上。而且，在问题分析和解决过程中，评价也是离不开分析性思维。甚至创造性思维也能得益于批判性思维，而我们可以把批判性思维（下一篇文章会讨论）归为分析性思维的一种思维方式。
说了这么多，还没谈到软件测试。别急，现在就来讨论：
软件测试和分析性思维究竟有什么关系？
分析性思维对软件测试究竟有多大价值？
分析性思维如何应用于软件测试中？
1. 软件测试和分析性思维之间的关系
传统的软件测试方法就是基于分析性思维构建起来的，或者说，第一个软件测试流派就是分析流派，把软件测试看作是软件工程（又是计算机科学、数学、管理科学等综合性学科）的一个分支，具有符合科学逻辑的、结构化的知识体系，相对客观、严谨、规范，完全可以分析、度量的。从这个角度看，人们通过分析能够完整理解软件，通过分析能够全面验证软件需求、设计和实现的一致性，软件测试是一门技术性强的工作。
[1] Bret Pettichord “Schools of Software Testing”
从软件测试工作本身看，测试就是发现软件的漏洞，就是对软件产品质量的评价，完全可以通过分析推理，发现软件需求、设计和实现上的漏洞，通过比较分析、综合性分析，依据客观数据（包括缺陷数据、性能指标等）来准确地评估软件质量。
看到这里，觉得没有收获，是不是感觉太理论了？也不是，谈到分析性思维，就需要我们理性，讲科学、重逻辑，先奠定这种思维方式，后面会有例子落地。通过上面的分析，实际上也清楚地告诉我们：软件测试是这么一回事、软件测试的工作如何去做...... 例如：
测试就是去验证需求和设计的一致性、代码和设计的一致性；
面对测试问题，可以构建测试模型、数据模型；
测试的效果（效率和质量）是可以度量的；
.....
软件测试的结构化方法都可以归为分析流派
2. 分析性思维对软件测试的价值
即使从其他软件测试流派的观点看，没有分析性思维，就无法完成软件测试。只是其它流派可能强调标准、质量模型、上下文等，终究离不开分析的过程，除非不需要思维，完全对照标准进行检查，或者有什么仪器能够自动读出数据，就能得出测试的结果。但现实中，我们还无法将产品需求、客户期望直接输入到某个工具中，就能得出测试结果（也许未来机器人可以做到这一点，机器人建造过程中需要人类更强的分析能力）。如果是这样，当然也不需要测试人员的工作
3. 分析性思维如何应用于软件测试中
在测试中要解决的问题很多，包括确定测试范围、测试风险排序、制定测试策略、设计测试用例、测试结果评估、产品质量评价等，这些地方都是分析性思维发挥巨大作用的地方。例如，就以“确定测试范围”为例，讨论一下如何运用分析性思维。
为什么要确定测试范围？确保测试能够达到测试目标。测试目标是什么？保证新实现的业务特性正常运行、已有业务不受影响？
为了确定测试范围，需要收集各种信息，例如这个项目哪些功能做了修改？从业务关系看哪些功能会受影响？还可以了解系统内部结构，或借助工具进行代码依赖性分析，了解如果哪些功能的代码修改了，会影响哪些代码、从而会影响哪些功能？新的版本会不会改数据库？产品线上的数据和改动的数据库是否兼容？最近一段时间，有没有新的终端设备、新的操作系统版本、新的浏览器版本发布？是否支持？开发会不会做代码重构？如果代码重构，会重构哪些模块的代码？性能、安全性、兼容性......有什么新要求？
整理获得的业务信息、运行环境信息？要修改的代码模块、受影响的代码信息，找出这些信息和测试范围之间的关系。
研发过程中，这些改动是确定的？会不会增加新的需求？哪些改动在什么情况下会取消？哪些需求相对明确？哪些需求相对不稳定？
基于项目质量、进度要求要求，基于对业务、系统的理解，确定测试项。
这里可能有些选项。如果开发质量达到预期水平而且能及时提测，测试范围可能会适当增加；如果开发质量比较差或代码耦合性偏高，测试范围要增大；如果开发提测时间延误，测试范围要缩小......
测试范围的确定主要平衡的就是效率和质量，而这取决于本项目的特点和特定的期望（项目目标）。清楚选择不同的测试范围，可能带来的测试风险或带来额外的测试工作量。
根据基于风险的测试策略和本项目的特定期望（质量第一 或 进度第一），来决定优先考虑的测试方案（范围选项）；
（具体案例具体分析，分析的思路会更清晰，而且会借助思维导图、业务流程图等进行分析，呈现会更直观 ）
分析性思维逻辑性强、系统性强，依据事实，按先后次序，一步一步地推理，客观、合理，最终会收敛到一点，就从“A——各种因素的输入”出发，通过分析，抽丝剥茧，去繁就简，最后得到“B——输出结果或结论”。下一篇会讨论“批判性思维”，将会更精彩。
参考文献
[1] https://en.wikipedia.org/wiki/Robert_Sternberg
[2] https://www.prismnet.com/~wazmo/papers/four_schools.pdf